Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

1. A Product Owner orders the work for a complex problem into a Product Backlog.

2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.

3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

4. Repeat

Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value. The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.

Customer Satisfaction, Customer Usage Index, and Customer or user satisfaction gap are Key Value Measures defined in the Evidence-Based Management (EBM) approach. It is an empirical approach that provides organizations with the ability to measure the value they deliver to customers.

A Product Backlog Item can be removed if it turns out to be irrelevant or obsolete. The Product Owner only focuses on value.

The Scrum Team consists of a Product Owner, Developers, and a Scrum Master.

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

Scrum is a framework for developing, delivering, and sustaining complex products.

The Product Owner is accountable for effective Product Backlog management, which includes:

● Developing and explicitly communicating the Product Goal;

● Creating and clearly communicating Product Backlog items;

● Ordering Product Backlog items; and,

● Ensuring that the Product Backlog is transparent, visible and understood.

The Product Backlog can contain initiatives, functional and non-functional needs, enhancements, ideas or any other product needs.

Scrum Teams are self-managed. The agile professionals organize themselves into Scrum Teams.

• The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.

• Enough work is planned during Sprint Planning for the Developers to forecast what it believes it can do in the upcoming Sprint.

Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.

The Product Owner and the Scrum Master SHOULD NOT be the same person for neutrality reasons.

However, nothing says that they CANNOT be the same person in the Scrum Guide.
That is not best practice as there would be a conflict of interest. But it is not forbidden as it can be more convenient for small teams of 4 people for example.

The Developers are responsible for all estimates. The Product Owner may influence the Developers by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

The Cone of Uncertainty describes the evolution of the amount of best case uncertainty during a project. At the beginning of a project, comparatively little is known about the product or work results, and so estimates are subject to large uncertainty. As more research and development is done, more information is learned about the project, and the uncertainty then tends to decrease.

Revenue is not the only measure of product’s value.
Users’ satisfaction is the best measure of product’s value.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.

The Scrum Master serves the Product Owner in several ways, including:

● Helping find techniques for effective Product Goal definition and Product Backlog management;

● Helping the Scrum Team understand the need for clear and concise Product Backlog items;

● Helping establish empirical product planning for a complex environment; and,

● Facilitating stakeholder collaboration as requested or needed.

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:

● Creating a plan for the Sprint, the Sprint Backlog;

● Instilling quality by adhering to a Definition of Done;

● Adapting their plan each day toward the Sprint Goal; and,

● Holding each other accountable as professionals.

The Developers modify the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Developers work through the plan and learn more about the work needed to achieve the Sprint Goal.

Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.

The Product Owner helps the Developers to build on the right thing (ie the envisioned Increment). The Developers help the Product Owner to make sound decisions on what the right thing is (ie Product Backlog item) and when it should be done (ie ordering of the Product Backlog). Therefore, their collaboration must be frequent.

As per the Scrum Guide version of 2020 : "Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal."

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:

● Creating a plan for the Sprint, the Sprint Backlog;

● Instilling quality by adhering to a Definition of Done;

● Adapting their plan each day toward the Sprint Goal; and,

● Holding each other accountable as professionals.

The ones closest to the problem are the best ones to understand and solve the problems.

The Scrum Master ensures that the Developers have the meeting, but the Developers are responsible for conducting the Daily Scrum. The Scrum Master teaches the Developers to keep the Daily Scrum within the 15-minute time-box.

Also, if the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

There must be one Product Owner per product.
The Product Owner is one person, not a committee.

No one can force the Developers of the Scrum Team to work from a different set of requirements.

Organizations adopting agile product delivery practices can easily lose sight of their real goal of improving the value they deliver, by focusing on improving activities and outputs instead of on business outcomes. Monitoring only the direct use of practices does not provide the best evidence of effectiveness; for example, tracking a Scrum Team's velocity says nothing about whether that team is actually delivering something that is useful to customers or users.

It's not mandatory in Scrum.org to start and end the Sprints at the same time. That makes it much more difficult to manage the whole project. It's not mandatory, because you may need it in certain cases: maybe some teams are working on parts of the project that need longer Sprints (four-week), while others need shorter ones (two-week) for shorter feedback loops.

The Definition of Done doesn’t need the Product Owner’s approval.

A Scrum Board, User Stories and Acceptance Criteria are good practices but not mandatory parts of Scrum (they are not even mentioned in the Scrum Guide).

The Product Owner is the sole person responsible for managing the Product Backlog. Therefore, he is the only person responsible for collecting feedback from the stakeholders in order the shape his product's vision.

While anyone in the Scrum Team can do the legwork at the Product Owner's discretion (by adding and ordering new Product Backlog Items for example), nobody can replace the Product Owner at the Sprint Review.

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Developers collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done.

Minimizing dependencies reduces complexity and enhances agility.

Scrum events should be held at the same time each Sprint. This helps with consistency, making improvements to the process, and reducing waste. In an event that a Scrum event cannot begin at the Scrum Team's designated time, they will need to inspect and adapt the event itself in order to maximize the effectiveness of the event. Delaying events is a short-term solution and results in reducing the team's opportunities to improve.

All Sprint Backlog Items are “owned” by the entire Scrum Team, even though each one may be done by an individual Developer.

A releasable increment must be delivered at the end of each Sprint. However, releasing that increment to production is not mandatory. It's done only when necessary. When it makes sense...

It is the responsibility of the Product Owner.

The objective of the Sprint is to produce a shippable Increment at the end of each Sprint so that the team can effectively inspect and adapt accordingly.

The Sprint Review includes the Scrum Team and key stakeholders invited by the Product Owner. During the Sprint Review the Product Owner: Explains what Product Backlog items have been 'Done' and what has not been 'Done'; Discusses the Product Backlog as it stands and any projections to date

Time-to-Market is a Key Value Area (KVA) of the Evidence Based Management (EBM) approach that expresses the organization’s ability to quickly deliver new capabilities, services, or products. Customer satisfaction is a Key Value Measure (KVM) under the Current Value KVA that helps gauge customer engagement and happiness with the product.

As a Product Owner, you have to find a balance in both delivering internal value and external value. Internal measures can be cost savings, FTE reductions, employee satisfaction, time spend on a certain (internal) process, revenues, etc. External measures can be customer satisfaction, NPS, etc.

As a Product Owner, releasing new features and/or functionalities every Sprint, maximizes value for your customers and users. You have to release a Product to customers/users, in order to find out if you have delivered value for them and to learn what they find valuable.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

Frequent releases to production are good practice to get some feedback from the market. However, releasing each increment is not mandatory.

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.

The purpose of the Sprint Retrospective is to:

• Inspect how the last Sprint went with regards to people, relationships, process, and tools;

• Identify and order the major items that went well and potential improvements; and,

• Create a plan for implementing improvements to the way the Scrum Team does its work.

The first team should spend time on interaction with the other teams and resolve dependencies. In the very beginning the productivity will decrease also because members of the first team will have to do some knowledge transfer to the new teams.

The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. The Product Owner works diligently to identify these needs. The Product Owner is responsible for ensuring that the status of the project is visible, transparent, and clear to all. At any point in time, the total work remaining to reach a goal can be summed and information is made transparent to all stakeholders.

The Scrum Master serves the Scrum Team in several ways, including:

● Coaching the team members in self-management and cross-functionality;

● Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;

● Causing the removal of impediments to the Scrum Team’s progress; and,

● Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Developers about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.

The Developers must follow the Definition of "Done" and are accountable for the quality of the Product Backlog items.

The ones doing the work are the best ones to create the estimations.

The earliest development of the Product Backlog lays out the initially known and best-understood requirements. It evolves as the product and the environment in which it will be used evolves and constantly changes to identify what the product needs to be appropriate, competitive, and useful.

The Developers are responsible for managing and tracking the progress of their work during a Sprint.

The Scrum Team can meet the Stakeholders whenever they need. During the Product Backlog Refinement sessions for example…

All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.

Scrum Teams are self-managed and cross-functional.

For a single product there is one Product Backlog. For a single Product Backlog there is one Product Owner.

The Developers use the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.

For a single product there is one Product Backlog. For a single Product Backlog there is one Product Owner.

There is always a Scrum Master in a Scrum Team

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

The Scrum Master is a true leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t.

The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

The Product Owner is accountable for optimizing the flow of value that the Developers create and the value that the Product delivers to its users. This is done through effective Product Backlog management. The Product Owner does not manage the rest of the Scrum Team and is entrusted to make the best decisions for the Product and business.

Non-functional requirements should be worked on alongside functional development.

Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.

Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

5 Scrum Events :

The Sprint
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective

While the Product Backlog must be ordered, ordering by priority is only one many techniques. The Product Backlog indeed must be ordered: its ordering determines the Product Backlog items' (PBI) order of delivery. The Developers can discuss Product Backlog Items ordering with the Product Owner but, in the end, the Developers must take the Product Backlog Items in the Product Backlog order. However, the Product Backlog is not guaranteed to represent an ordering of PBIs by either value or priority. You can’t just assign priorities to the PBIs — whether they come from the ROI or importance to the business or anywhere else — and then prioritize the backlog on the basis of those relative values. As a Product Owner, you must consider the entire backlog of PBIs together. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is in charge of monitoring the TCO (Total Cost of Ownership) and this entails contemplating all the investments (conception, development, operation and maintenance) to be made in the product. For example, quality impacts the TCO and life expectancy of a product. Getting software out of the door quickly with poor quality may achieve a short-term win but it incurs technical debt. The software becomes difficult to extend and maintain. This results in high cost and long lead times for new functionality. And software with poor quality often has to be replaced sooner rather then later resulting in a short life expectancy and a poor return on investment. A Product Owner is ultimately concerned with Maximizing Return On Investment (ROI), optimizing Total Cost of Ownership (TCO), and capitalizing on product Agility

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

The Scrum Team consists of a Product Owner, the Developers, and a Scrum Master.

There is only one Product Backlog

The ones doing the work are the best ones to decide what they can do and how to do it.

All work to be done by the Developers must ultimately come from the Product Backlog as it is the single source of product requirement. How the work is done can change, evolve, and emerge as more is learned.

Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.

The Scrum Master serves the Scrum Team in several ways, including:

● Coaching the team members in self-management and cross-functionality;

● Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;

● Causing the removal of impediments to the Scrum Team’s progress; and,

● Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:

● Creating a plan for the Sprint, the Sprint Backlog;

● Instilling quality by adhering to a Definition of Done;

● Adapting their plan each day toward the Sprint Goal; and,

● Holding each other accountable as professionals.

Developers deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it. If the definition of "Done" for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum.

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.

The Developers are always accountable for:

● Creating a plan for the Sprint, the Sprint Backlog;

● Instilling quality by adhering to a Definition of Done;

● Adapting their plan each day toward the Sprint Goal; and,

● Holding each other accountable as professionals.

The Product Owner is responsible for the Product Backlog. Who adds the items and how they are added to the Product Backlog vary widely across organizations, Scrum Teams, and individuals.

“Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.”

Having a clear and inspiring Product vision helps in motivating and inspiring the people involved and affected by the product. It also provides a common understanding of the direction we are working towards. It also supports the Product Owner in making choices about what to build and what not to build for the Product.

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:

● Creating a plan for the Sprint, the Sprint Backlog;

● Instilling quality by adhering to a Definition of Done;

● Adapting their plan each day toward the Sprint Goal; and,

● Holding each other accountable as professionals.

The Product Owner may consider the dependencies between Product Backlog Items but not the dependencies of the software tools used by the Developers.

A new Sprint starts immediately after the conclusion of the previous Sprint.

The Scrum Master serves the Product Owner in several ways, including:

● Helping find techniques for effective Product Goal definition and Product Backlog management;

● Helping the Scrum Team understand the need for clear and concise Product Backlog items;

● Helping establish empirical product planning for a complex environment; and,

● Facilitating stakeholder collaboration as requested or needed.

Early and frequent releases of usable increments offer more opportunities for valuable feedback.

The Scrum Master serves the Scrum Team in several ways, including:

● Coaching the team members in self-management and cross-functionality;

● Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;

● Causing the removal of impediments to the Scrum Team’s progress; and,

● Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase.

The only outcome of each Sprint is a potentially releasable Increment of “Done” product.

A “Done” increment is required at the Sprint Review.

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Developers about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.

It's the responsibility of the Developers to estimate the amount of work of Product Backlog items and to select appropriate number of them for each Sprint. They also break down the items into tasks during the Sprint.
Measuring the project performance is the responsibility of the Product Owner, while measuring the Sprint performance is done by the Developers. Creating new Product Backlog items, ordering them (prioritization) and making sure that everyone has a clear understanding of them is the responsibility of the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Developers to work from a different set of requirements.

The definition of “Done” provides the same shared understanding and transparency of what has been done at the end of the Sprint.

Sprint Planning addresses the following topics:

Topic One: Why is this Sprint valuable?

Topic Two: What can be Done this Sprint?

Topic Three: How will the chosen work get done?

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one- month Sprint. For shorter Sprints, the event is usually shorter.

Stakeholders can be invited to Backlog Refinement sessions as needed.

Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog. Also the dependencies between Product Backlog items may be taken into consideration.

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is also accountable for effective Product Backlog management, which includes:

● Developing and explicitly communicating the Product Goal;

● Creating and clearly communicating Product Backlog items;

● Ordering Product Backlog items; and,

● Ensuring that the Product Backlog is transparent, visible and understood.

Burn-down chart shows the amount of work left to be done, versus the time allocated for the iteration. Burn-down charts are an efficient tracking tool, because they show when the work remaining is projected to be completed if nothing changes on the backlog or Scrum Team. The burn-down chart is a helpful tool for the Scrum Teams to self-manage BUT it is not mandatory as the Scrum Teams will decide the best way to manage their own progress and promote transparency.

Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one- month Sprint. For shorter Sprints, the event is usually shorter.

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”.

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

Technical debt is a concept in programming that reflects the extra development and testing work that arises when 'quick and dirty' solutions result in later remediation. It creates an undesirable impact on the delivery of value and an avoidable increase in waste and risk.

The Product Owner is  accountable for effective Product Backlog management, which includes:

● Developing and explicitly communicating the Product Goal;

● Creating and clearly communicating Product Backlog items;

● Ordering Product Backlog items; and,

● Ensuring that the Product Backlog is transparent, visible and understood.

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Developers' level of knowledge. This is a key inspect and adapt meeting.

The Product Backlog is a living artifact that evolves and changes as more is learned.

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.

As a Product Owner, releasing new features and/or functionalities every Sprint, maximizes value for your customers and users. You have to release a Product to customers/users, in order to find out if you have delivered value for them and to learn what they find valuable and feed the information into the Product Backlog.

Scrum Teams are self-managed. The agile professionals organize themselves into Scrum Teams.

The Product Backlog is a living artifact that evolves and changes as more is learned.

The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.

Agile is all about depending on adaptation, instead of predictive (static, upfront) plan and design.

The Scrum Review is also an opportunity to collect customer / user feedback from the Stakeholders.

Scrum Teams are self-managing and cross-functional. Self-managing teams choose how best to accomplish their work, rather than being directed by others outside the team.

Scrum prescribes four formal events for inspection and adaptation:

- Sprint Planning

- Daily Scrum

- Sprint Review

- Sprint Retrospective

The Increment can be released at the end of every Sprint, but it is not mandatory.

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. In other words it can be defined as the longer term consequences of poor design decisions. Technical debt is a real risk which can genuinely be incurred. It compromises long­-term quality of the Product. One of the ways of handling technical debt is recording it on the Product Backlog. So, it becomes visible to the Scrum Team.

The the defined terminology in Scrum was selected, designed, and defined specifically for supporting the Scrum Framework. Understanding the differences between traditional methods and the Scrum Framework will help move teams in the right direction in Scrum adoption.

The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.

Sprint Planning answers the following:

- What can be delivered in the Increment resulting from the upcoming Sprint?

- How will the work needed to deliver the Increment be achieved?

There's usually room for improving the definition of "Done". A good definition will let less technical debt pass on to the next Sprints. Technical debt is minor shortcomings in the code that makes it less than "good enough" and therefore creates risks in the future. It usually decreases velocity in the future (because the team has to fix the shortcomings) and as some of the debt might remain in the final product, the maintenance cost will increase as well. Another Agile way of reducing technical debt is continuous refactoring.

A first Sprint requires no more than a Product Owner, a team, and enough ideas to potentially complete a full Sprint.

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. The Items in the current Sprint are no longer on the Product Backlog, because they are now on the Sprint Backlog. However, it is certainly fine for the Product Owner to add detail and clarification to the current Sprint’s work as well.

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

Definition of Done is used to assess when work is complete on the product Increment. Guides the Developers in knowing how many Product Backlog items it can select during a Sprint Planning. Definition of Done ensures artifact transparency.

The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.

The Developers use the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Developers will meet the Sprint Goal. Everyday, the Developers should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

The Product Owner must take the dependencies into consideration to order the Product Backlog (along with the value of the Product Backlog Items or any criteria that seems relevant to the Product Owner).

The Sprint is cancelled only in the case if the Sprint Goal became obsolete. If some work could not be done, the Sprint Backlog should be renegotiated between the Product Owner and the Developers.